Access Control System and Method

ABSTRACT

Certain embodiments of the invention relate to an access control system defining one or more compartments and providing rules, which are applied to the compartment(s), to control access to network services by entities that are associated with a said compartment, the rules comprising at least a first kind of rule for controlling access to network services that use dynamically-assigned communications ports.

RELATED APPLICATIONS

This patent application claims priority to Indian patent applicationserial number 1380/CHE/2007, having title “ACCESS CONTROL SYSTEM ANDMETHOD”, filed on 27 Jun. 2007 in India (IN), commonly assignedherewith, and hereby incorporated by reference.

FIELD OF THE INVENTION

The present invention relates to access rights in computer systems.

BACKGROUND OF THE INVENTION

Operating systems are typically computer programs or sets of computerprograms that are loaded into a computer's memory and executed in orderto control the subsequent operation of a computer. However, operatingsystems can also be embedded programs in firmware or hardware,particularly, for example, in portable devices such as mobile telephonesand PDAs

Most, traditional computer operating systems offer some kind of logicalprotection to data in the form of access controls, which can be grantedor denied to specific people or groups of people. Generally, in a systemthat offers discretionary access control (DAC) a user (as opposed to anadministrator) is able to assign permissions to their data, which permitor deny others (or groups of others) access to the data. This is finefor individuals. However, some organisations, such as military orgovernment organisations in particular, require the ability to moreclosely control access to information. For example, top secretinformation should not be visible to most people in an organisation,restricted information, as the label suggests, should not be generallyavailable, whereas unrestricted information may be available for accessby anyone in an organisation.

Accordingly, secure operating systems are known, which provide greateraccess control over an organisation's information. Typically, secureoperating systems associate additional classifications or labels withfiles and apply so-called mandatory access control (MAC), which providesa means of restricting access to the files based on their sensitivity(for example, as represented by a sensitivity label). In contrast toDAC, under MAC a user does not have the right to determine who seestheir data: only users having a compatible clearance are permitted tosee the data. For example, a user with top secret clearance would nothave the ability to permit others with a lesser clearance to see theirdata.

MAC can be expressed in terms of “compartments”. In practice, acompartment is typically a logical construct having an identifier suchas a name, applied to which are a set of administrator-configured accesscontrol rules that define the compartment. Compartment rules are used topermit access only to those resources (such as files, processes andinter-process communication methods) necessary for an application toexecute. These rules apply both to users and processes that havepermission to operate in the compartment, and, accordingly, unlessotherwise stated or unless the context dictates otherwise, such usersand processes will be referred to herein generally as “entities”.

Thus, entities operating within a compartment can by default only accessfiles, other process and resources that are defined to be accessible inthe same compartment, unless specific MAC rules are provided to thecontrary.

Compartments can provide an isolated runtime environment for anapplication, wherein the compartment rules allow access to only thoseresources that are necessary for the application to execute. Thisincreases the likelihood that, even when an application is compromised,the damage is limited only to the compartment(s) where the applicationis running.

In addition to controlling access to file systems and the like, it isknown for MAC to be used to control access to resources that are outsideof a compartment, such as network end-points providing remote servicesgenerally and, more particularly, network services, by defining MACrules, which grant or deny access to particular communicationsinterfaces of a computing platform. As used herein, the term “network(or networked) service” is a computer program, which runs on a remotecomputer, or server, in a distributed computing environment of networkedcomputers. Network services can be accessed, invoked, or “called”, froma client (for example a host running a secure operating system), whichis remote from the server running the service. Examples of networkservices are RPC services (such as ypserv, mountd etc), Web sites,X-terminals and FTP sites, to name just a few of the well-knownservices.

The ability to control access to network services increases security, byproviding mechanisms for preventing an entity from accessing networkservices that may have been, or may in future be, compromised. The mostcommon way in which a network service can be compromised is from adenial-of-service-attack, which floods the service (or server runningthe service) with dummy requests for service, in an attempt to renderthe service unavailable to legitimate users.

One known way of defining MAC for resource access is based on so-calledlabelled security protection profiles (LSPP), where the resource (forexample, a network end-point) is arranged to carry a label thatspecifies the access control policy on the resource. However,implementing MAC in this way requires a significant amount of effort andadaptation to traditional applications and operating systems. A knownsimpler way of defining MAC for resource access is based on using accesscontrol rules, which are specified for each individual compartment. Suchcontrol rules typically use TCP port numbers to uniquely identifynetwork end-points, for example network services. Many network servicesuse well-known, pre-assigned port numbers; for example, HTTP uses TCPport 80, POP3 uses port 110 and IRC uses port 194. In such cases, it ispossible to grant or deny access to the services by granting or denyingaccess to the respective ports using MAC rules. However, some networkservices, such as RPC services and XTERM services, do not usepre-assigned port numbers (that is, the port numbers are allocated orassigned dynamically at run time) and it is, therefore, not possible togrant or deny access by specifying port number in compartment rules. Inthe absence of such access control, if any such network service iscompromised, then it may not be easy to contain or control the damagethat can be done to an otherwise secure system.

It is an object of embodiments of the invention to at least mitigate oneor more of the problems of the prior art.

SUMMARY OF THE INVENTION

In accordance with one aspect of the present invention, there isprovided an access control system defining one or more compartments andproviding rules, which are applied to the compartment(s), to controlaccess to network services by entities that are associated with a saidcompartment, the rules comprising at least a first kind of rule forcontrolling access to network services that use dynamically-assignedcommunications ports.

In accordance with another aspect of the present invention, there isprovided an access control method comprising:

receiving a network service call from a requesting entity, which isassociated with a compartment of a secure operating system, the saidnetwork service using a dynamically assigned communications port;

determining, with respect to any rules that have been applied to thecompartment, whether the entity has permission to access the networkservice; and

processing the network service call only if an applied compartment rulegrants permission to access the network service.

In accordance with yet another aspect of the present invention, there isprovided a data processing system arranged to process a network servicecall, comprising:

an input for receiving, from an entity that is associated with acompartment of the system, a call for a network service that uses adynamically assigned communications port;

a store storing rules that are applied to compartments and which defineassociated network service access permissions; and

a process which enacts the network service call only if the storecontains a said compartment rule that grants permission to access thenetwork service.

Known secure operating systems are SELinux™, Trusted Solaris™ and HP-UXSecurity Containment™, and embodiments of aspects of the presentinvention can be applied to these operating systems, although theprinciples taught are more widely applicable.

Further features and advantages of the invention will become apparentfrom the following description of preferred embodiments of theinvention, given by way of example only, which is made with reference tothe accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram showing an exemplary computing environment suitablefor operation according to embodiments of the present invention;

FIG. 2 is a diagram showing an exemplary motherboard for use with acomputing platform of the kind shown in FIG. 1;

FIG. 3 is a schematic diagram illustrating three computing platforms ina distributed computing environment; the first platform operating as anRPC server, the second one operating as a client executing acompartmented operating system and the third one operating as a Webserver;

FIG. 4 is a schematic diagram illustrating the functional elements of asecure operating system that are necessary for implementing anembodiment of the present invention;

FIG. 5 is a flow diagram showing steps involved in controlling access toa network service according to an embodiment of the present invention;and

FIG. 6 is a flow diagram showing the steps involved in defining newcompartment Mandatory Access Control rules for network services whichuse dynamic port assignments.

DETAILED DESCRIPTION OF THE INVENTION

While it is known to be able to control access to (or use of) networkservices, which use known port numbers, embodiments of the presentinvention relate to a new class of compartment rule, which controlsaccess to (or use of) network services which use dynamically assignedport numbers.

Before describing embodiments of the invention in detail, a computingenvironment suitable for implementing certain embodiments of theinvention will now be described.

An exemplary computing platform 10 suitable for implementing embodimentsof the invention is illustrated in the diagram in FIG. 1. The computingplatform 10 has the standard features of a keyboard 14, a mouse 16 and avisual display unit (VDU) 18, which provide the physical ‘userinterface’ of the platform. The platform contains standard componentssuch as a mother board and a hard disk drive for storing a file system.

As illustrated in FIG. 2, the motherboard 20 of the computing platform10 includes (among other standard components) a main processor 21, mainmemory 22, a data bus 26 and respective addressing lines 27 and controllines 28, BIOS memory 29 containing the BIOS program for the platform 10and an Input/Output (IO) controller 25. The IO controller 25 (which maycomprise one or more independent subsystems) controls interactionbetween the components of the motherboard and connected devices such asthe keyboard 14 and the mouse 16 (via an input controller 253), the VDU18 (via an output controller 254, for example a screen or graphicscontroller), a storage device 12 such as a hard disk (via a storagecontroller 252) and the outside world (via a network controller 251, forexample an Ethernet LAN controller), which may be embodied on a networkinterface card (NIC). Communications with the outside world, for exampleacross the Internet, are directed via the network controller 251 and,typically, include data packets. In known systems, the data packets aretypically addressed to travel via a logical port number of a NIC or thelike, as will be described in more detail hereinafter.

The main memory 22 is typically random access memory (RAM) and the BIOSmemory is typically EEPROM, which can be ‘flashed’ with BIOS updates. Inoperation, the platform 10 loads the BIOS from the BIOS memory 29 and,in turn, loads an operating system from the hard disk 12 into RAM. Theoperating system controls every aspect of the operation of the computingplatform and, in the present example, is a secure operating system thatprovides compartments. Additionally, in operation, the operating systemloads the processes or applications that may be executed by the platform10 into RAM 22 from hard disk 12.

The diagram in FIG. 3 illustrates a network scenario wherein there arethree networked computers labelled Machine 1 (300), Machine 2 (310) andMachine 3 (320). Machine 1 is a server which runs the RPC networkservices rpcbind 301, ypserv 302 and rpc.mountd 303. These RPC servicesuse dynamically assigned port numbers 304 on a network card 305. Machine2 is running a secure operating system 312, which defines threecompartments, designated ‘File Sharing’ 313, ‘ifaces’ 314 and ‘Database’315, which can communicate using ports 315 of a network card 314.Machine 3 is running a Web Server 322, which uses the pre-assigned portnumber 80 (325) on a network card 324. The shaded regions in the diagramrepresent a communications fabric or infrastructure, for exampleprovided by a LAN, between the machines: a first shaded region 330illustrates that Machine 1 and Machine 2 can in principle communicatewith each other and a second shaded region 340 indicates that Machine 2and Machine 3 can in principle communicate with each other. However, forcommunications to take place, logical connections (either packet orstreams based) have to be established. One such logical connection,which permits communications to take place between port 81 of Machine 2and port 80 of Machine 3, is shown by a solid arrow designated as 350.

It is possible to control access, by an entity operating in acompartment of Machine 2, to the Web Server 322 on Machine 3, usingknown secure operating systems, which can control access to networkservices that use fixed port number assignments and compartment-specificrules based on port number (or, more specifically, NIC, destination IPaddress and port number). An exemplary known rule of this kind will nowbe described by way of background and has the syntax:

-   -   “access, direction, protocol, port (port number), peer port        (port number), compartment”,        where: access is set to grant or deny; direction dictates        whether the rule applies to a client (outbound message from        compartment) or to a server (inbound message to compartment);        protocol can be set, for example, as TCP or UDP (or any other        recognised protocol); port is a port of the machine containing        the compartment; peer port is the port used by the machine        containing the service (or network endpoint); and compartment is        an identifier or name of a compartment which is associated with        the network (or LAN) interface, which is used for the        communications. For example, an access rule for a compartment        called “File Sharing” might appear as:

[prior art MAC rule] 10 compartment File_Sharing { 20    grant servertcp port 81 peer port 80 ifaces 30    deny client tcp port 81 peer port80 ifaces 40 } 50 compartment ifaces { 60    interface lan0 70 }

This access rule has the following meaning: line 10 names thecompartment as File Sharing; line 20 grants the access control right tocompartment File Sharing to receive from TCP port 80 of a remotecomputer (designated by server), TCP-protocol inbound communications toTCP port 81, which is associated with the interface card designated lan0(not shown), which itself is associated with the compartment calledifaces; line 30 grants the access control right to compartment FileSharing (designated by client) for outgoing TCP communications from TCPport 81, through the lan0 interface card to TCP port 80 of a remotecomputer; line 40 ends the definition of the File Sharing Compartment;line 50 begins a definition of a compartment called ifaces; line 60,defines the ifaces Compartment to contain the lan0 interface (such thatan entity of any other compartment can only communicate via the lan0interface if it has permissions to access the ifaces compartment, as hasbeen granted in lines 20 and 30 to the File Sharing Compartment); andline 70 ends the definition of the ifaces Compartment. It is known thatPort 80 is the TCP port associated with HTTP, which is used fortransferring web pages and, therefore, the File Sharing Compartment has,by the foregoing access control rules, been granted permission tointeract with a Web Server.

In contrast with the ability to control access between the File SharingCompartment 313 and the Web Server 322, it is not possible (using theclass of rules described above) to grant access by the File SharingCompartment 313 to the RPC services hosted by Machine 1, while at thesame time denying access by the Database Compartment 315 to the RPCservices on Machine 1; as the ports 305 on Machine 1 are dynamicallyassigned (and the respective port numbers are, therefore, labelled “?”as being unknown) and the rules cannot be applied.

However, according to certain embodiments of the present invention, aswill be described, independent network service access control for eachof the compartments can be achieved. As will be described in detailherein, embodiments of the present invention depend on a new class ofrule, which is designed to control access network services which usedynamically assigned port assignments. The new rule can be represented,by way of example, as follows:

-   -   DPR G/D <MODULE> <STRING>        where: DPR is the rule name, which represents “Dynamic Port        Rule”; G/D is the permission GRANT or DENY; <MODULE> is the name        of the network service (and a corresponding module or function,        which will be described) to which the rule applies; and <STRING>        is a unique identifier (which could be a number, a name or any        other kind of reference) that is associated with the named        network service (and the corresponding module or function).

The diagram in FIG. 4 provides a high-level functional representation ofa portion of an exemplary secure operating system, which has beenadapted for operation according to the present embodiment. It isemphasised that embodiments of the invention are in no way limited tothe arrangement or architecture illustrated in FIG. 4. One example of asecure operating system on which certain embodiments of the inventionmay be practiced is HP-UX Security Containment, version 2, release11.31, which provides MAC and can be adapted as described herein tooffer network services access rules, on a per-compartment basis, tonetwork services that use dynamically-assigned ports. It will beappreciated, however, that certain embodiments of the invention may beimplemented on other existing secure operating systems, and theprinciples described herein are in no way limited to application in theHP-UX product.

In the example that follows, the operating system is a compartment-basedoperating system offering MAC, which is implemented (in relation tonetwork services) using compartment rules, as will be described. Theoperating system supports UNIX-like commands, existing rules forcontrolling access to network services that have known port numbers, andthe new rule for controlling access to network services that havedynamically assigned port numbers. Again, embodiments of the inventionare in no way limited to UNIX-like operating systems. For example, theprinciples could be applied equally to a Microsoft™ Windows™ basedoperating system or, indeed, to any other kind of operating system,including bespoke or embedded operating systems or the like.

The operating system 400 in FIG. 4 is shown having a Kernel Space 402,which is memory reserved for running the kernel of the operating system,and a User Space 404. The kernel is generally responsible for managingthe computing platform's resources and the communications between thehardware and software components. The User Space 404 is a memory areawhere user applications execute and operate. The User Space 404 receivesinput from the user (via the mouse 16 or keyboard 14—sometimes referredto as the ‘standard input’) and passes it on to a System Call Interface406. In the present context, when the input relates to a networkservices request of some kind, the command is passed by the System CallInterface 406 to a Network Services Handler 408.

The Network Services Handler 408 is a software program or function inthe operating system (or called by the operating system) that processesnetwork service calls with reference to access control rules which areprovided by a Security Containment Controller 410. The SecurityContainment Controller 410 contains MAC rules in a Security ContainmentRules function 412. The Security Containment Rules function 412 containsthe rules in general defining each of the compartments of the system. Inparticular, the Security Containment Rules function 412, according tothe present embodiment of the invention, includes rules defining networkservice access controls for compartments, as will be described below inmore detail.

The Network Services Handler 408 establishes, by reference to theSecurity Containment Controller 410, if an entity (that is, a user or aprocess), which is associated with a compartment, and which has issued anetwork services call, has the access control rights necessary for thecall to be invoked and completed. If the entity has the rights then theNetwork Service Handler 408 executes the associated network servicescall, in a known way, and interacts with a LAN Card Controller 414(which uses BIOS calls), to interact with a respective network servicesserver 300 via a LAN card 416 and LAN 330. If the entity does not havethe rights, then access is denied in the traditional manner.

In relation in particular to the network services access control rules,as shown in FIG. 4, the Security Containment Rules function 412 includesa table 418 containing entries 420, for each identified compartment, foreach network service that has been assigned access control permissions.In the example shown, only one table entry 420 for the “FS” Compartmentis shown; and it will be appreciated that, in practice, there may bemany rules for various compartments for which access controls arerequired. In principle, a compartment does not need any particular rule,in which case the default position is that entities operating in thecompartment are denied access to respective network services.

As shown in FIG. 4, the compartment rules table 418 comprises acompartment name or ID column 420, a module name column 422 and apointer column 424, where each row of the table (that is, each modulename entry for an identified compartment) has a corresponding pointer.In this example, the pointers 426 (in the pointer column 424) arepreferably ‘opaque pointers’, which provides the known advantage thatthe pointer is generic, so that it can support any kind of networkservice that uses dynamic port numbers (for example, RPC services andXTERM services), although, other kinds of pointer, which are specific toeach kind of network service, may be used instead. Each of the pointers426 points to a corresponding Access Check Module 428, which providesthe MAC rule for the associated network service. In the case of the RPCnetwork service, for example (and as illustrated), the module 428 nameis “RPC”, representing the service, and the pointer 426 points to anAccess Check Module 428 for the RPC service. As already indicated, thismodule name is associated with a compartment called “FS” (which could bethe File Sharing Compartment of FIG. 3). In this instance of the AccessCheck Module 428, access (for entities in the FS compartment) to the RPCservice (identified by RPC Prog Number) is GRANT.

Each Access Check Module provides the MAC rules for the respectivenetwork service. As each network service is different, each Access CheckModule will comprise appropriate respective functionality and will tendto operate in a different way, typically with different requirements forinput (that is, different input arguments), but having the same kind ofMAC output, which will be to GRANT or DENY access to the respectivenetwork service.

In principle, it may be necessary to have a number of differentinstances of each kind of Access Check Module; for example, there may beplural instances of the RPC Access Check Module, since differentcompartments may (and likely will) have different access controlrequirements for the RPC service (or, indeed, any other service). Forexample, the second entry 430 in the rules table relates to the “DB”compartment (which could be the Database Compartment 315 in FIG. 3). Arespective pointer 432 for the DB entry 430 identifies a second RPCAccess Check Module 434, which, in this instance, denies access to theidentified RPC service. Indeed, absence of a compartment rule for anyparticular network service would also lead to the access being denied,thereby avoiding the situation where there needs to be an Access CheckModule for every combination of defined compartment and network service.

However, while the same network service may need multiple Access CheckModules to cater for the requirements of different compartments, if twoor more compartments have the same access control requirements for agiven network service, then two respective entries in the compartmentrules table 418 may point to the same Access Check Module.

By way of illustration only, the last entry 440 in the compartment rulestable 418 is shown to relate to an arbitrary network service ‘xyz’,which could be any network service which uses dynamically-assignedports, and a respective pointer 442 points to an appropriate AccessCheck Module 444, which denies access to the network service.

An exemplary network service MAC process will be described withreference to the flow diagram in FIG. 5. In this example, an RPC servicecall will be described, but, first, for background understandingpurposes only, the RPC service will be described in general terms.

An exemplary remote procedure call according to RPC involves a callerprocess sending a call message to a server process and waiting for areply message. The call message contains the parameters of the procedureand the reply message contains the procedure results of running theprocedure. When the caller process receives the reply message, itcontinues executing. On the server side, the RPC service is typicallydormant, awaiting the arrival of a respective RPC call message. When anRPC call message arrives, the service computes a reply that it thensends back to the requesting caller process.

In general, an RPC service may be identified at least by its RPC programnumber, version number, and a transport address where it may be reached.A version number is used to differentiate between various differentversions of the same service, and is mostly utilised to evolve theservice over time. The transport address, in turn, consists of a networkaddress and a transport selector. In the case of a service availableover TCP or UDP, the network address is an IP address, and the transportselector is a TCP or UDP port number. A caller process needs to know theRPC program number, version number, and the transport addresscorresponding to a service in order to utilize the service. Of these,the RPC program number and version number may be built into the callerprocess as part of the service definition. The network address componentof the transport address is usually obtainable from a name servicedaemon, such as “named” (for example, found in HP-UX in the directorypath /usr/sbin/named), or may be provided as a parameter to the callerprocess. As already explained herein, for RPC services, the transportselector (that is, the TCP or UDP port) is usually determineddynamically, and varies with each invocation of the service. Serverprograms allocate a transport address, and register it with a lookupservice (such as rpcbind, or bind), which is associated with a fixedtransport selector (that is, TCP port number 111), and resides at thesame network address as the server. Caller processes are typically ableto consult the lookup service in order to obtain the server's transportaddress, following which the RPC service can be invoked and completed.

Now, returning to FIG. 5, in a first step 500 the system receives an RPCcall, for example, for the ypserv RPC service. The RPC call is receivedincluding the RPC program number for ypserv, which is 100004. Generally,in known systems, RPC calls are received in a machine by a known RPCservice (or process), which is called rpc_call( ), which expects toreceive a number of arguments or parameters, including RPC programnumber and version number. According to the present embodiment, when theRPC call is received by the System Call Interface 406, it is recognisedas a network service call and passed to the Network Services Handler408. The Network Services Handler 408 incorporates a modified version ofrpc_call( ) process. The rpc_call( ) process is adapted by the inclusionof a new security containment function call, for example having theform:

“network_services_mac_access_check (               network_service_name,                rpc_info_pointer,               compartment).”

According to the present ypserv example, thenetwork_services_mac_access_check( ) arguments are:

network_service_name = “RPC” rpc_info_pointer = 100004 compartment = FS

For other services, such as XTERM, an equivalent to the rpc_call( )process would be adapted to include a network_services_mac_access check() function call (or ‘hook’), although, of course, the parameters wouldmatch those required for the XTERM service rather than those for the RPCservice. The network_services_mac_access_check( ) function itself ispart of the Security Containment Controller.

In the next step 505 in FIG. 5, the network_services_mac_access_check( )function searches the Security Containment Rules function 412 toidentify an entry which corresponds both to the FS compartment and tothe Module Name “RPC”. In step 510, if an entry does not exist, then thedefault response is that the access control request is denied in step515, and the response is passed back, via thenetwork_services_mac_access_check(_) function to the rpc_call( )process, and the calling entity is informed in the traditional way thataccess is denied. If, however, the entry exists (which it does accordingto FIG. 4), then, in step 520, the respective opaque pointer 426 is usedto identify the corresponding Access Check Module 428. If the moduledoes not exist, in step 525, then, again, the default response is thatthe access request is denied in step 515. If the module exists (which isdoes, named “RPC Access Check Module” in FIG. 4) then, in step 530, themodule uses the rpc_info_pointer value to identify a respective accesspermission for the ypserv procedure. Although not illustrated in orderto reduce complexity in the diagram in FIG. 4, the RPC Access CheckModule 434 contains a table defining the access control rules for one ormore RPC network services and logic for searching for an appropriateaccess control rule for the specified service (identified by the RPCProg Number). In step 535, if the access permission is present and isGRANT, then, in step 540, access to the service is granted, andpermission is passed back via the network_services_mac_access_check( )function to the rpc_call( ) process, which undertakes to invoke the RPCservice in interactions with the target RPC server in the normal way. Ifthe access permission is “DENY” (or there is no access permission setfor the specified RPC network service), then the access permission isdenied, in step 515, the response is passed back, via thenetwork_services_mac_access_checko function to the rpc_call( ) process,and the calling entity is informed in the traditional way that access isdenied.

Network service access permissions are set according to the presentembodiment by adding appropriate entries to the Security ContainmentRules function 412, which is used by the Security Containment Controller410, as illustrated in the diagram in FIG. 4.

An example of setting network service access permissions, according toembodiments of the present invention, in the HP-UX Security Containmentsecure operating system, will now be described for the exemplarycompartment called “FS”. The access permissions, like other compartmentrules, are entered into a text file (in the HP-UX product) calleddatabase.rules. The text file takes the following form:

compartment FS {    DPR G RPC 100003 {grant access to ‘NFS’}   DPR G RPC 100004 {grant access to ‘ypserv’}    DPR G RPC100005 {grant access to ‘mountd’}    DPR G RPC 100006 {grant access to‘rpcbind’}    DPR G XTERM putty {grant access to 1^(st) xterm service,   ‘putty’}    DPR D XTERM refx {deny access to 2^(nd) xterm service,   ‘refx’} }

The above defines a compartment called ‘FS’ and defines MAC rulesgranting access to the RPC services ‘NFS’, ‘ypserv’ and ‘mountd’, inaddition to granting access to a first XTERM service ‘putty’ and denyingaccess to a second XTERM service ‘refx’.

A similar text structure would be provided for every other compartmentfor which MAC rules are required.

According to the HP-UX Security Containment operating system, which, ashas been described, can be adapted to operate according to embodimentsof the present invention, compartment and respective MAC rules aretypically loaded into the Security Containment Rules function 412 usinga program called setrules, which is found in the system directory/usr/sbin. The setrules program is arranged to parse database.rules andset each rule for a compartment in turn. The setrules program isarranged to read database.rules from a system directory called/etc/cmpt, which is where the systems administrator must storedatabase.rules.

The system administrator executes setrules using the following commandline:

-   -   #/usr/sbin/setrules

The secure operating system illustrated in FIG. 4 includes a functionalblock 450 representing the setrules program. As already described, theprogram resides in a specified directory /usr/sbin/setrules, but isshown as part of the Security Containment Controller 410, as it providesan interface, which enables a systems administrator to set upcompartments on the basis of a text file definition, rather than havingto access and generate or modify kernel code or associated definitions.When a systems administrator wishes to set up a compartment by definingits MAC policy as described above, they generate a text file, forexample called database.rules, and store it in the /etc/cmpt directory.They then issue a command line such as:

-   -   #/usr/sbin/setrules        to initiate the generation of the compartment. The System Call        Interface 406 receives the command input, recognises it and        forwards it to a Set Access Handler 452, which in turn accesses        the setrules function and loads the compartment definitions.

An exemplary process for building a MAC rule for accessing a networkservice which uses a dynamically assigned port number will now bedescribed with reference to the flow diagram in FIG. 6, which is basedon the compartment definition described above for the FS compartment.

In a first step 600 in FIG. 6, the System Call Interface 406 receives asetrules command and passes it to the Set Access Handler 452. The SetAccess Handler 452 invokes the setrules program in step 605. Thesetrules program accesses the database.rules file and parses the firstlines of definition text in step 610. In this example, the first line ofthe definition file defines a new compartment called “FS”. In step 615,if the line is a compartment definition line then, in step 620, a newcompartment entry is added to a compartment list (not shown) for thesecure operating system, any subsequent MAC rules are associated withthat compartment and the process returns to step 610 wherein the nextline of definition text is parsed. If, in step 615, the line is a DPRrule for a compartment, then the process continues with step 625. Inthis example, only the process for the DPR rule is included, and it willbe appreciated that other known and equivalent procedures would beprovided for such other rule kinds. In step 625, the process identifies(using the <MODULE> field) if the rule is an addition to an existingAccess Check Module or if the rule requires the generation of a newAccess Check Module. If the rule relates to a new Access Check Module,in step 630 the process finds an appropriate RPC service template for arespective Access Check Module (where each known service for which arule may be set has a pre-defined template, providing the framework fora specific Access Check Module) and generates a new Access Check Module(using the <MODULE> field as the identifier, the <STRING> value 100003to fill the RPC Prog Number field and the G/D value is the permission).In step 635, the process adds an entry to the rules table 418; the entrycomprising a first field 420 containing the compartment ID, a secondfield 422 containing the module name and an opaque pointer (in the thirdfield 424), which points the table entry to the Access Check Modulecode. Next, in step 640, the process determines if there are any morerules in the definition. If there are more rules to define, then theprocess returns to step 610 to parse the next line of the definition. Ifthere are no more rules to define then the process ends in step 645.

If, in step 625, it is determined that the new rule adds to an existingAccess Check Module, then, in step 650, the process adds an entry to theexisting Access Check Module using the <STRING> value 100003 to fill theRPC Prog Number field and the G/D value is the permission. The processthen continues with step 640.

The process in FIG. 6 repeats for each rule in the definition until nonew rules are found and the process ends. The result is that the rulestable is populated with references to all compartment rules that areneeded for controlling access to network services by the secureoperating system.

The above embodiments are to be understood as illustrative examples ofthe invention. Further embodiments of the invention are envisaged. Whileit has been indicated that certain embodiments of the invention may beimplemented by adapting an HP-UX Security Containment secure operatingsystem, other embodiments may be implemented by adapting other knownsecure operating systems such as SELinux™ or Trusted Solaris™, or,indeed, any other secure operating system that can be adapted to definecompartment rules for accessing network services that use dynamicallyassigned ports.

It will be appreciated that embodiments of the present invention can berealised in the form of hardware, software or a combination of hardwareand software. Any such software may be stored in the form of volatile ornon-volatile storage such as, for example, a storage device like a ROM,whether erasable or rewritable or not, or in the form of memory such as,for example, RAM, memory chips, devices or integrated circuits or on anoptically or magnetically readable medium such as, for example, a CD,DVD, magnetic disk or magnetic tape. It will be appreciated that thestorage devices and storage media are embodiments of machine-readablestorage that are suitable for storing a program or programs that, whenexecuted, implement embodiments of the present invention. Accordingly,embodiments provide a program comprising code for implementing a systemor method as claimed in any preceding claim and a machine readablestorage storing such a program. Still further, embodiments of thepresent invention may be conveyed electronically via any medium such asa communication signal carried over a wired or wireless connection andembodiments suitably encompass the same.

All of the features disclosed in this specification (including anyaccompanying claims, abstract and drawings), and/or all of the steps ofany method or process so disclosed, may be combined in any combination,except combinations where at least some of such features and/or stepsare mutually exclusive.

Each feature disclosed in this specification (including any accompanyingclaims, abstract and drawings), may be replaced by alternative featuresserving the same, equivalent or similar purpose, unless expressly statedotherwise. Thus, unless expressly stated otherwise, each featuredisclosed is one example only of a generic series of equivalent orsimilar features.

The invention is not restricted to the details of any foregoingembodiments. The invention extends to any novel one, or any novelcombination, of the features disclosed in this specification (includingany accompanying claims, abstract and drawings), or to any novel one, orany novel combination, of the steps of any method or process sodisclosed. The claims should not be construed to cover merely theforegoing embodiments, but also any embodiments which fall within thescope of the claims.

1. An access control system defining one or more compartments andproviding rules, which are applied to the compartment(s), to controlaccess to network services by entities that are associated with a saidcompartment, the rules comprising at least a first kind of rule forcontrolling access to network services that use dynamically-assignedcommunications ports.
 2. The system of claim 1, comprising a second kindof rule for controlling access to network services that use pre-assignedcommunications ports.
 3. The system of claim 2, wherein the first kindof rule is different from the second kind of rule.
 4. The system ofclaim 1, wherein the first kind of rule is defined independently of anycommunication port.
 5. The system of claim 1, wherein the first kind ofrule is defined with respect to a network service identifier.
 6. Thesystem of claim 1, wherein applied rules are identified in a rules tableof the system.
 7. The system of claim 6, wherein applied rules aredefined in modules, wherein the rules table identifies each applied ruleand includes an associated pointer to the respective module.
 8. Thesystem of claim 7, wherein the pointer is an opaque pointer.
 9. Thesystem of claim 1, comprising a network services handler for receivingnetwork services calls from entities.
 10. The system of claim 9, whereinthe network services handler is arranged to receive a network servicescall, redirect the system to establish, with respect to applied accesscontrol rules, if a said calling entity has permission to access theidentified network service, and process the network services call onlyif an applied rule grants permission to access to the network service.11. The system of claim 9, wherein the network services handlercomprises rpc_call( ) functionality for processing network servicescalls.
 12. The system of claim 11, which includes a function call, whichcalls a function for establishing if the calling entity has rights toaccess the network service.
 13. The system of claim 1, which appliesMandatory Access Control rules to control access to network services.14. The system of claim 1, comprising a secure operating system.
 15. Theaccess control system according to claim 1, providing access controlrules for controlling access to RPC network services.
 16. An accesscontrol method comprising: receiving a network service call from arequesting entity, which is associated with a compartment of a secureoperating system, the said network service using a dynamically assignedcommunications port; determining, with respect to any rules that havebeen applied to the compartment, whether the entity has permission toaccess the network service; and processing the network service call onlyif an applied compartment rule grants permission to access the networkservice.
 17. A data processing system arranged to process a networkservice call, comprising: an input for receiving, from an entity that isassociated with a compartment of the system, a call for a networkservice that uses a dynamically assigned communications port; a storestoring rules that are applied to compartments and which defineassociated network service access permissions; and a process whichenacts the network service call only if the store contains a saidcompartment rule that grants permission to access the network service.